home *** CD-ROM | disk | FTP | other *** search
/ Deutsche Edition 1 / Deutsche Edition 1.iso / amok / 011-020 / amok16 / memsystem / memsystem.dok < prev    next >
Text File  |  1993-11-04  |  11KB  |  270 lines
  1. ======================================================================
  2. Dokumentation zu "MemSystem" Version 1.3
  3. Autor: Nicolas Benezan, Postwiesenstr. 2, D7000 Stuttgart 60
  4. ======================================================================
  5.  
  6. Kopierrecht
  7. ­­­­­­­­­­­
  8. Das komplette Packet (Quelltext, Dokumentation und Objectcode) ist
  9. Public Domain Software. Es darf beliebig kopiert und verbreitet werden
  10. solange...
  11.  
  12. * mein Name und dieser Kopierrechtshinweis erhalten bleiben,
  13. * die Vollständigkeit des ganzen Packets gewährleistet ist, und
  14. * mit dem Vertrieb dieser Software kein Gewinn erwirtschaftet wird.
  15.  
  16. Die Kommerzielle Nutzung ohne meine ausdrückliche schriftliche
  17. Genehmigung ist untersagt.
  18. Ferner ist allen Personen, die in irgend einer Weise etwas mit "Data
  19. Becker" zu tun haben, insbesondere für "Data Becker" arbeiten oder
  20. deren Produkte verkaufen, jegliche Verwendung dieser Software verboten.
  21.  
  22. Verbesserungsvorschläge sind stets willkommen. Falls Sie Veränderungen
  23. am Programm vornehmen, dokumentieren Sie diese bitte gut verständlich.
  24. Es würde mich freuen, wenn Sie mich über größere Veränderungen in
  25. Kenntnis setzen würden.
  26.  
  27. (c) 1988 by Nicolas Benezan.
  28.  
  29.  
  30. Übersicht
  31. ­­­­­­­­­
  32. * Umfang des Packets
  33. * Einleitung
  34. * Das Modul MemSystem
  35.   - Allocate, AllocMem, Deallocate
  36.   - NoCareAllocate, NoCareAllocMem, NoCareDeallocate
  37.   - MinMemory, Hysteresis
  38.   - EnterLevel, ExitLevel
  39. * Das Modul ErrorReq
  40.   - YesNoRequest
  41.   - ErrHeader
  42.   - RecoverableExit
  43.   - DeadEndExit
  44.   - ExitQuiet
  45.   - Assert
  46. * Das Modul TaskMemory
  47.  
  48.  
  49. Umfang des Packet
  50. ­­­­­­­­­­­­­­­­­
  51. Das komplette Packet "MemSystem" beinhaltet folgendes:
  52.  
  53. * MemSystem.dok                         Diese Dokumentation
  54. * MemSystem.doc                         Englische Dokumentation
  55.  
  56. * MemSystem.def, -.mod, -.sym, -.obj    V1.3
  57. * ErrorReq.def, -.mod, -.sym, -.obj     V1.2
  58. * TaskMemory.def, -.mod, -.sym, -.obj   V1.1
  59.  
  60. * TestMemSys.mod, -.obj                 Testmodul Quellcode, Objektdatei
  61. * TestMemSys                            ausführbares Testprogramm
  62.  
  63. (Stand 29.Mar.1989)
  64.  
  65.  
  66. Einleitung
  67. ­­­­­­­­­­
  68. MemSystem ist ein Speicherverwaltungsmodul, das gegenüber dem Standardmodul
  69. "Heap" folgende Vorteile aufweist:
  70.  
  71. * es ist voll Multitaskingfähig, d.h. es kann vom Hauptmodul importiert und
  72.   von mehreren Tasks aus parallel benutzt werden. Dabei wird allozierter
  73.   Speicher immer in der MemList des aufrufenden Tasks eingetragen. Bei
  74.   Beendigung des Tasks (mit RemTask oder bei Process-Termination) wird der
  75.   gesammte mit MemSystem verwaltete Speicher freigegeben.
  76. * Wird mehr Speicher angefordert als frei ist, wird dies nicht sofort mit
  77.   NIL beantwortet, sondern ein Requester (Retry/Cancel) erzeugt. Der Benutzer
  78.   hat somit die Möglichkeit, z.B. einige Workbench-Windows zu schließen, um
  79.   es dann noch einmal zu probieren. Der Programmieraufwand ist praktisch
  80.   null, entgegen der sonst üblichen Methode, dach jedem AllocMem() auf NIL zu
  81.   testen, den Requester anzuzeigen ...
  82. * System-Deadlocks, die durch extremen Speichermangel hervorgerufen werden
  83.   können, werden verhindert. Viele Programme erzeugen bei Speichermangel eine
  84.   Meldung mit AutoRequest() (zB. auch der Modula-Compiler). Es wird aber oft
  85.   vergessen, daß der Requester selbst auch Speicher benötigt. MemSystem
  86.   berücksichtigt dies.
  87.  
  88. Neu: Version 1.3
  89. ----------------
  90. Neu sind die Prozeduren NoCareAllocate, NoCareAllocMem und NoCareDeallocate,
  91. die eine vereinfachte Fehlerbehandlung erlauben.
  92. Dazugekommen ist außerdem die Levelbehandlung, die es ermöglicht, sämtlichen
  93. in einer bestimmten Programmebene (Level) allozierten Speicher zurückzugeben.
  94.  
  95.  
  96. Das Modul MemSystem
  97. ­­­­­­­­­­­­­­­­­­­
  98. Dieses Modul ist sozusagen das Hauptmodul des Packets. Es exportiert die
  99. High-Level-Prozeduren zur Speicherverwaltung und importiert die Module
  100. ErrorReq und TaskMemory, welche die Low-Level-Prozeduren enthalten.
  101.  
  102. Allocate(), AllocMem(), Deallocate()
  103. ------------------------------------
  104. Diese Prozeduren entsprechen in der Schnittstelle sowie in der Handhabung
  105. genau den gleichnamigen Prozeduren von Heap. Allerdings läuft beim
  106. allozieren von Speicher für das aufrufende Programm unsichtbar noch
  107. folgendes ab:
  108. * Es wird getestet, ob Size+MinMemory (siehe unten) Speicher frei ist.
  109. * falls nicht wird ein Requester (Low Memory Warning Retry/Cancel) erzeugt.
  110.   Bei "Retry" wird noch einmal versucht, die angeforderte Speichermenge zur
  111.   Verfügung zu stellen. Bei "Cancel" wird NIL zurückgegeben, wie man es von
  112.   Heap bei Speichermangel kennt.
  113. * falls doch wird der Speicher wie gewohnt alloziert. Der Speicherbereich
  114.   wird in der MemList des aufrufenden Tasks oder Prozesses registriert.
  115. Einwandfreie Funktion ist auch bei mehreren parallellaufenden Tasks, die
  116. auch unabhängig voneinander erzeugt und terminiert werden können,
  117. gewährleistet. Die Prozeduren sind reentrant.
  118. Ein Deallozieren von Speicher, den man gar nicht alloziert oder schon
  119. freigegeben hat führt nicht zum Guru, sondern wird abgefangen.
  120.  
  121. NoCareAllocate(), NoCareAllocMem(), NoCareDeallocate()
  122. ------------------------------------------------------
  123. Diese Prozeduren bewirken das gleiche wie die vorherigen, es entfällt
  124. jedoch die Notwendigkeit, auf mögliche Fehler zu testen. Somit
  125. vereinfacht sich die Programmierung. Die Prozeduren sollten jedoch
  126. nicht aus Bequemlichkeit ständig verwendet werden - dadurch schafft
  127. man nicht weniger sondern eher mehr Bugs! Verwenden Sie sie nur dort,
  128. wo sie sinnvoll und notwendig sind!
  129. NoCareAllocate() und NoCareAllocMem() bringen wie die normalen Allocate-
  130. Prozeduren bei Speichermangel den Retry/Cancel Requester. Wird jedoch
  131. Cancel gewählt wird das Programm abgebrochen (mit ErrorReq.ExitQuiet).
  132. Man braucht deshalb nach NoCareAllocate() nicht auf NIL zu testen, sondern
  133. kann davon ausgehen, daß der Speicher in jedem Fall zur Verfügung steht.
  134. Dies ist vor allem bei kleinen Programmen sehr bequem.
  135. Bei größeren, mit denen man Projekte bearbeiten kann, sollte jedoch darauf
  136. verzichtet werden, und der umständliche Weg gewählt werden, damit man zum
  137. Beispiel dem Benutzer noch ermöglichen kann, seine Arbeit zu speichern.
  138. Denn es kommt leicht zu einem Wutausbruch, wenn ein Programm nach
  139. mehrstündigem Arbeiten meint: "Not enough memory", und ohne Warnung
  140. abbricht.
  141. NoCareDeallocate() ist eine gutmütigere Version von Deallocate(), die
  142. sich nicht beklagt, wenn Speicher mehrmals freigegeben wird.
  143. Anwendungsbeispiel - verzeigerte Liste:
  144.  
  145. root --> node --> node --> node --> node --> NIL
  146.           |         \      /         |
  147.           |          \    /          |
  148.           |           \  /           |
  149.           V            VV            V
  150.         Data1        Data2         Data3
  151.  
  152. TYPE    Node=RECORD
  153.           next:NodePtr;
  154.           data:DataPtr;
  155.         END;
  156.  
  157. node:=root
  158. WHILE node#NIL DO
  159.   NoCareDeallocate(node^.data);
  160.   node:=node^.next;
  161. END;
  162.  
  163. NoCareDeallocate() ist hier notwendig, weil zwei Nodes den
  164. selben Datenbereich haben.
  165.  
  166. EnterLevel(), ExitLevel()
  167. -------------------------
  168. Speicher, der mit MemSystem alloziert wird, wird bei Beendigung des
  169. Tasks/Programms automatisch freigegeben. Manchmal ist es jedoch
  170. wünschenswert schon vorher bestimmte Teile davon freizugeben.
  171. Zum Beispiel soll eine Prozedur am Ende allen Speicher freigeben, den
  172. sie alloziert hat. Dies ist möglich, wenn an deren Anfang EnterLevel()
  173. und am Schluß ExitLevel() steht. Mit ExitLevel wird dann der Speicher
  174. freigegeben, der seit dem zugehörigen EnterLevel() alloziert wurde.
  175. ExitLevel() verläßt automatisch auch alle tieferen Level. Beispiel:
  176.  
  177.   VAR     Inner,Outer:LevelKey;
  178.   ...
  179.   EnterLevel(Outer);
  180.   ...
  181.   EnterLevel(Inner);
  182.  
  183. jetzt wäre
  184.  
  185.   ExitLevel(Outer);
  186.  
  187. gleichbedeutend mit
  188.  
  189.   ExitLevel(Inner);
  190.   ExitLevel(Outer);
  191.  
  192. Jedem Level wird mit EnterLevel() ein (für diesen Task) eindeutiger
  193. Schlüssel (opaker Typ LevelKey) vergeben.
  194.  
  195. MinMemory
  196. ---------
  197. gibt die größe des Speichers an, der minimal noch freibleiben muß, damit
  198. die korrekte Funktion des Systems gewährleistet ist. Default ist 20kB, was
  199. für einige Notfall-Requester oder Alerts ausreicht.
  200.  
  201. Hysteresis
  202. ----------
  203. Damit nach einem Speichermangel wieder Speicher alloziert werden kann, muß
  204. mindestens minMemory+Hysteresis Speicher frei sein. Die Hysterese wurde
  205. eingeführt, damit bei einem Arbeiten an der minMemory-Grenze nicht all paar
  206. Sekunden ein Requester erscheint, sondern der Speicher nach einem
  207. erfolgreichen "Retry" wieder für eine Weile reicht. Default ist 30kB.
  208.  
  209.  
  210. Das Modul ErrorReq
  211. ­­­­­­­­­­­­­­­­­­
  212. Dieses Modul wird von MemSystem benutzt und beinhaltet einige nützliche
  213. Prozeduren zum Anzeigen von einfachen Requestern und zum Abbrechen des
  214. Programms.
  215.  
  216. YesNoRequest()
  217. --------------
  218. Dies ist eine Vereinfachung von Intuition.AutoRequest(). Sie wird intern von
  219. Allocate, AllocMem (bei Speichermangel) und von RecoverableExit verwendet.
  220. Als "Zugabe" wurde die Prozedur auch im Definition-Module aufgeführt und
  221. somit für jedermann zugänglich gemacht. Die Parameter dürften
  222. selbsterklärend sein (siehe auch Arts.Request() ).
  223.  
  224. ErrHeader()
  225. -----------
  226. Ist die Überschrift jedes Requesters, der von ErrorReq erzeugt wird
  227. (Default ist "Modula-2 Error Handler").
  228.  
  229. RecoverableExit()
  230. -----------------
  231. Dies ist gewissermaßen die Kombination aus Arts.BreakPoint und Arts.Error.
  232. Während BreakPoint nach beantworten des Requesters immer weitermacht, und
  233. Error immer abbricht, kann der Benutzer bei RecoverableExit selbst
  234. entscheiden.
  235. Die Prozedur verwndet die Variable ErrHeader (siehe dort).
  236.  
  237. DeadEndExit()
  238. -------------
  239. Entspricht Arts.Error, mit dem Unterschied, daß nicht die häßliche Meldung
  240. "Modula-2 Programmunterbruch" erscheint. Stattdessen wird ErrHeader
  241. und darunter der angegebene Text angezeigt.
  242.  
  243. ExitQuiet()
  244. -----------
  245. ermöglicht das korrekte beenden des Programms von jeder beliebigen Stelle
  246. aus. Ebenso wie auch bei DeadEndExit und RecoverableExit funktioniert
  247. hierbei der TermProcedure-Mechanismus ordnungsgemäß.
  248.  
  249. Assert()
  250. --------
  251. ist dem Assert von Arts ähnlich. Wenn die zu überprüfende Bedingung FALSE
  252. ist, wird eine Meldung ausgegeben und Das Programm abgebrochen. Wurde
  253. das Programm von der Workbench gestartet, wird ein DeadEndExit-Requester
  254. erzeugt, ansonsten der Text direkt im CLI-Fenster ausgegeben.
  255.  
  256.  
  257. Das Modul TaskMemory
  258. ­­­­­­­­­­­­­­­­­­­­
  259. Dieses Modul beinhaltet die Low-Level-Prozeduren für MemSystem. Sie
  260. wurden vom Hauptmodul getrennt, um zu verhindern, daß sehr kleine
  261. Programme, die die umfangreichen Funktionen von MemSystem nicht benötigen,
  262. sich unnötig aufblähen, weil wegen wenigen Prozeduren ein riesiges
  263. Modul dazugelinkt wird.
  264. Die Prozeduren sind wie die von MemSystem reentrant und voll multitasking-
  265. fähig. Sie unterstützen jedoch keine Requester und geben bei einem
  266. Fehlschlag wie die Exec- und Heap-Prozeduren einfach NIL zurück.
  267. AllocTaskMem() ist zu Exec.AllocMem() parameterkompatibel, Allocate(),
  268. AllocMem() und Deallocate() jeweils zu der entsprechenden Heap-Prozedur.
  269.  
  270.